Netlify deploy preview

https://deploy-preview-44401--material-ui.netlify.app/

Bundle size report

Details of bundle changes (Toolpad)
Details of bundle changes

Generated by 🚫 dangerJS against 7ea5845

Hey @ZeeshanTamboli, thanks for working on this.

We do want the ownerState to be available for the transition slots. That way, users can consume it when building their custom transitions. The responsibility of filtering ownerState would be on the developer.

The fix here should be to filter out the ownerState inside the Fade and Zoom components. Because those are our transition components, the responsibility of not forwarding ownerState incorrectly should be handled on each one. Does this make sense?

Hey @ZeeshanTamboli, thanks for working on this.

We do want the ownerState to be available for the transition slots. That way, users can consume it when building their custom transitions. The responsibility of filtering ownerState would be on the developer.

The fix here should be to filter out the ownerState inside the Fade and Zoom components. Because those are our transition components, the responsibility of not forwarding ownerState incorrectly should be handled on each one. Does this make sense?

Oh, I thought the ownerState passed to the slotProps callback through resolveComponentProps in useSlot was sufficient. For example:

slotProps={{ transition: ({ expanded }) => (expanded ? 300 : null) }}

For non-transition slots, I assumed ownerState was appended for use in the styled API for styling.

Is that not the case?

The responsibility of filtering ownerState would be on the developer.

Do we document this somewhere?

Oh, I thought the ownerState passed to the slotProps callback through resolveComponentProps in useSlot was sufficient.

For non-transition slots, I assumed ownerState was appended for use in the styled API for styling.
Is that not the case?

Both of these are useful, but IMO don't cover all use cases. Making the parent's ownerState available as a prop provides more flexibility. There's also an argument for not providing the ownerState but only certain properties of it. This is another thing we need to decide regarding the slot pattern cc: @siriwatknp

Do we document this somewhere?

No. Documentation about slots could and should be much better. We're working on improving that, but first, we want to implement the missing slots throughout the components.

@DiegoAndai What's your take on the recent pushed change to destructure ownerState?